feat: attest integration #6963
feat: attest integration #6963
Conversation
…to feat-skip-snapshot-serialize
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
hi-ogawa
force-pushed
the
feat-attest-integration
branch
from
51bdf11
to
caec8a1
Compare
hi-ogawa
force-pushed
the
feat-attest-integration
branch
from
caec8a1
to
ee471ed
Compare
@vitest/coverage-istanbul
@vitest/expect
@vitest/mocker
@vitest/browser
@vitest/coverage-v8
@vitest/pretty-format
@vitest/runner
@vitest/snapshot
@vitest/spy
@vitest/ui
@vitest/utils
vite-node
vitest
@vitest/web-worker
@vitest/ws-client
commit: |
|
Perhaps it would be useful to add more complex examples? I tried to play with a recursive type: import { expect, test } from 'vitest';
type JsonValue = string | number | boolean | JsonObject | Array<JsonValue>;
interface JsonObject {
[key: string]: JsonValue;
}
function stringify(input: JsonValue): string {
return JSON.stringify(input);
};
test('stringify', () => {
expect(stringify).toMatchTypeInlineSnapshot(`(input: JsonValue) => string`);
});Do you think this snapshot is good? I mean, it will fail if name of the argument gets changed, although that’s not really important. But it will pass if type is redefined into JSX components were mention in #5857, so here is an attempt: interface ButtonProps {
text: string;
type?: "reset" | "submit";
}
function Button({ text, type }: ButtonProps) {
return <button type={type}>{text}</button>;
}
test('Button', () => {
expect(Button).toMatchTypeInlineSnapshot(`({ text, type }: ButtonProps) => Element`);
});Good to see names of props, but if |
|
@mrazauskas Hi, first of all, thanks for testing out! About what's printed in the snapshot, we've talked with arktype/attest author @ssalbdivad. If I remember correctly, that's what we can get from ts server api. Normally it should match with what you see when hovering on IDE, but vscode can somehow show namespace without getting stripped. We're not familiar with this area, so mostly we'll need to delegate to what attest supports for now even if we integrate some features as Vitest builtin. I guess this feature will start as experimental and see if the representation makes sense to users in general. |
Fair enough. I mean.. Are you about to ship this feature knowing that you are not familiar with it? |
|
In terms of API, I'm mostly only using This in turn uses |
Description
Based on #6852, now I moved all code to core.
summary
Add new assertions:
toMatchTypeSnapshot/toMatchTypeInlineSnapshottoMatchTypeErrorSnapshot/toMatchTypeErrorInlineSnapshottoMatchTypeCompletionSnapshot/toMatchTypeCompletionInlineSnapshotand a new option to "enable" them (without the option, assertions become no-op and no-error):
vitest --attestdefineConfig({ test: { attest: true } })Example on stackblitz https://stackblitz.com/edit/vitest-dev-vitest-ywts26?file=test%2Fbasic.test.ts
example code
todo
ATTEST_tsconfignew Error().stackfor for non type assertionexpect(xxx)(how?)PrettyFormatSkipSnapshotErrorhackATTEST_assertionCacheDiroption https://github.com/arktypeio/arktype/blob/a5f7e4b2b857f2275e8ea03d9895d12db3076b42/ark/attest/config.ts#L149-L151getFileKey? https://github.com/arktypeio/arktype/blob/776ce7e85becf7614b4ad4def65d0d90df9c908a/ark/attest/utils.ts#L5expect(xxx)(can be later)fsandprocesson runtime (later for browser mode)tbd
{ attest: true })Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Documentation
pnpm run docscommand.Changesets
feat:,fix:,perf:,docs:, orchore:.